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(57) ABSTRACT 

A method of address resolution for the transfer of voice and 
voice data calls through multiple domains in a broadband 
data network is described. The implementation of broadband 
data networks as transport backbones for voice and voice 
data calls requires address resolution to determine the des- 
tination node for each call. Because of the projected fre- 
quency at which new access peripherals will be added to 
such broadband data networks, manual maintenance of 
translation tables is impractical. The invention therefore 
provides an automated method for address resolution which 
permits voice interface control units associated with the 
broadband data network nodes to automatically maintain the 
required translation tables. Next-hop resolution routing 
tables may be maintained at every node or only at nodes 
designated as signaling gateways between broadband data 
network domains. If the broadband data network is an ATM 
network, switched virtual circuits are set up in reverse from 
ATM destination nodes in order to reduce call admission and 
setup, time. The advantage is automated maintenance of 
translation tables which may be tailored to meet the oper- 
ating policy of network managers that control respective 
domains. 

39 Claims, 8 Drawing Sheets 
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FIG. 2a 



Category 


Type 


Purpose 


Content 


REQUEST 


i 


Intra-domain Initialization - to 
populate all nodes in the 
same domain with DNs 
served by requesting node; 
RESPONSE is mandatory 


REQUEST{type=l;seq.#; 
source=Al , PI ; destination = 
A3, P3; TTL= 1 ; local DN list (81 9- 
212 ....819-997)} 


RESPONSE 


i 


Intra-domain Initialization - to 
populate requesting node 
with DNs served by a node 
receiving type 1 request 


RESPONSE{type=l;seq.#; 
source=A6, P6; destination=Al , 
PI; local DN list (61 3-230.... 61 3- 
780)} 


REQUEST 


2 


Intra-domain Update - to 
notify neighbor nodes of DN 
changes or flood translation 
entries; RESPONSE is optional 


REQUEST{type=2; seq.#; 
source=Al , PI ; destination =Ax, 
Px; TTL«1; local DN list (819-210 
....819-953)} OR 
REQUEST{type=2; seq,#; 
source^Al , PI ; destination=A3, 
P3; TTL=1; translation 
entries(61 3-230, P6, A6. . .61 3- 
780, P6, A6)} 


RESPONSE 


2 


Intra-domain Update - to 
acknowledge type 2 
REQUEST, with or without 
content 


RESPONSE{type=2; seq.#; 
source=A6, P6; destination =A 1 , 
PI} 


REQUEST 


3 


Translation entry query for 
information respecting the 
identity of a node that serves 
a particular DN OR 
Inter-domain REQUEST for 
gateway translation entries 
(*[... ]" indicates optional 
content) 


REQUEST{type=3;seq.#; 
source=Al, PI; destination =A2, 
P2; TTL=5; [local DN list (819- 
210 ....819-953)]; translation 
entry query (DN=51 4-833); PC 
Stack=Pl} OR 
REQUEST{type=3; seq.#; 
(source=A4 ( P4); destination^ 
Ax, Px; TTL=4; group (Al, PI: 
domain DN list (514-112 .,..819- 
997); PC Stack=P4} 



FTG. 2h 
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Category 


Type 


Purpose 


Content 


RESPONSE 


3 


Translation entry query 
RESPONSE for providing 

If lliJin IvJlUJt i ItroJJtri-'lll ty lilt? 

Identity of a node that serves 
a particular DN OR 
Inter-domain RESPONSE for 
gateway translation entries 

y [• < <J ii hjio^jiwD WfJiiwi iui 

content) 


RESPONSE{type=3; seq.#; 
source =A5, P5; destl nation =A1 , 

PI ■ Moroni DM Ikt 0 

r 1 , [IUUUI U-/IM Mol \o 1 *4 C 1 u 

....514-711)]; translation query 
entry (DN-51 4-833; A5, P5); 
Original PC Stack= PI ,P2,P5; PC 
Stack=Pl,P2} OR 

w l. ur v^i not ^ i yj-/w — Ji oCoj . tt , 

source=C4, P44; dest=A4,P4; 
group (C4, P44: domain DN list 
(416-210 ....519-953); Original 
PC Stack= P4,P8,P12,P44; PC 
Stnrk= P4 PR PI ?\ 


REQUEST 


4 


Inter-domain REQUEST to 
notify other gateways of 
changes to a domain DN list, 
response is expected but 
content is optional 


REQUEST{type=4; seq.#; 
(source =A4, P4); destination = 
A2, P2; nL=4; group(A4, P4: 
domain DN list (514-112 ....819- 
997)]; PC Stack=P4} 


RESPONSE 


4 


Inter-domain RESPONSE to 


RESPONSE{type=4; seq.#; 

ccm irr-d — C*A PAA' Hoci — HA PA* 

Original PC Stack= 
P4,P2,P5.P44; PC Stack= 
P4.P2.P5} 


REQUEST 


5 


Next-hop routing REQUEST 
with reverse SVC setup to 

ouiuin u ifUiioiuiivji i tJiiny iui 
the DN, and to concurrently 
set up call path from the 
destination node to the 
originating node 


REQUEST{type=5; seq.#; 
source =A4, P4; destination = A3, 

rO, ML — O, IIVji lolUIKJM t?l IIIIWo 

query(DN = 21 2-1 23-1 234), PC 
Stack=Pl ; SVC Request (traffic 
contract, VCCI=xl)} 


KtOr VJINOC 


O 


QP^PONKF tr> nc^Yt-hnn mi itinn 
i\cor \_/(Noi-. \\j i icai i ivuiii ly 

REQUEST to provide 
translation entry information 
for the DN 


source=C2, P42; destination- 
A4,P4; translation entry query 
(DN=212-123, PC-P42, 
ASEA=AC2); traffic contract, 
VCCI=xl; PC Stack=P4, P3} 


REQUEST 


6 


Next-hop routing REQUEST 
with reverse SVC setup, 
without translation entry query 


REQUEST{type=6; seq.#; 
source =A4, P4; destination =D3, 
P3;TTL=6; PC Stack=P4; SVC 
Request (traffic contract, 
VCCI=xl . . . )} 


RESPONSE 


6 


RESPONSE to reverse SVC 
setup REQUEST, without 
translation entry information 


RESPONSE{type=6; seq.#; 
source=D3, P3; destination =A4, 
P4; PC Stack=P4,P6,P44; SVC 
Request (traffic contract, 
VCCI=xl)} 



FIG. 2c 
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1 2 

rlETHGE Or ADDRESS RESOLUTION FOR uiuuipie domains in a broadband data network. Trie re also 

THE TRANSFER OF SYNCHRONOUS exists a need for a messaging protocol for called number 

TRANSFER MODE CALLS THROUGH address resolution in a multiple domain control network 

MULTIPLE DOMAINS IN A BROADBAND adapted to control the transfer of STM calls between STM 

DATA NETWORK 5 switches using a broadband data backbone. 



TECHNICAL FIELD 

This invention relates generally to synchronous transfer 
mode (STM) call completions and, in particular, to the io 
completion of calls which originate and terminate in an STM 
network but at least a portion of the call connection is 
completed using a broadband data network, for example an 
asynchronous transfer mode (ATM) network or an Internet 
Protocol (IP) network. 15 

BACKGROUND OF THE INVENTION 

Multi -service broadband networks built using ATM or IP 
protocols are gaining acceptance as the preferred transport 
backbone for STM service providers because they permit the 2 q 
service providers to consolidate their voice and data traffic 
on a single multi-service facility. Consequently, the use or 
the desire to use ATM/IP networks as transport backbones 
for STM calls is rapidly increasing. As new facilities are 
added to ATM/IP networks for the admission of STM calls, 25 
a problem arises respecting address resolution to determine 
an appropriate broadband data destination node for servicing 
each call admission request. 

Call setup and control in the public switched telephone 
network (PSTN) is generally e fleeted using an out-of-band 30 
signaling network known as a common channel signaling 
network. Most of the North American PSTN is equipped to 
operate with a common channel signaling protocol called 
Signaling System 7 (SS7). ATM networks, for example, use 
a different signaling protocol in which signaling messages 35 
are transported through the network in cells like those used 
for carrying payload data. The signaling systems of the 
PSTN and ATM networks are therefore incompatible and 
STM calls cannot be transferred directly to or from an ATM 
network. Although it is possible to adapt an ATM network to 40 
operate under the control of a common channel signaling 
network, as taught in U.S. Pat. No. 5,568,475 entitled "ATM 
NETWORK ARCHITECTURE EMPLOYING A COM- 
MON CHANNEL SIGNALING NETWORK", which 
issued on Oct. 22, 1996 to Doshi et al, it is less expensive 45 
and preferable to permit the ATM multi-service carrier 
network to operate autonomously with its native signaling 
system. This minimizes expense while enabling efficient use 
of ATM network resources. The same applies to the use of 
multi-service IP networks which currently run on a dynamic 50 
routing system for the purpose of data services, and one not 
adapted to support signaling. 

In the STM network, time division multiplex switches are 
arranged in a hierarchy which minimizes address encoding 
and permits calls to be completed with a minimum of 55 
address resolution. A factor which contributes to the effi- 
ciency of broadband data networks is that such a switch 
hierarchy does not exist. While this lack of hierarchy con- 
tributes to network efficiency and versatility, it imposes a 
requirement for address resolution to enable STM calls to be so 
transferred through the ATM network at an acceptable call 
setup rate. Likewise, an address resolution system is 
required to enable STM calls to be transferred through an IP 
network because IP does not support the PSTN numbering 
system. 65 

There therefore exists a need for a method of address 
resolution to enable the transfer of STM calls through 



SUMMARY OF THE INVENTION 

It is an object of the invention to provide a method of 
address resolution for the transfer of STM calls through a 
broadband data network which enables automated data fill 
and maintenance of translation tables to enable address 
resolution. 

It is a further object of the invention to provide a method 
of address resolution for the transfer of STM calls through 
multiple domains in a broadband data network in which a 
switched virtual circuit is set up from a destination node for 
a call in order to minimize call setup time. 

It is yet a further object of the invention to provide a 
method of address resolution for the transfer of STM calls 
through multiple domains across a broadband data network 
in which each domain includes at least one voice gateway 
node having a control virtual circuit established with a peer 
voice gateway node in an adjacent domain. 

It is a further object of the invention to provide a method 
in which voice gateway nodes maintain next-hop call reso- 
lution routing tables which enable call routing without 
requiring a complete address mapping table indicating the 
destination node to serve a dialled number 

It is yet another object of the invention to provide a 
method of address resolution for the transfer of STM calls 
through a broadband data network in which all nodes in a 
domain of the broadband data network maintain a complete 
map of dialled numbers served by nodes in the domain. 

These and other objects of the invention are realized by a 
method of address resolution for the transfer of synchronous 
transfer mode (STM) calls through multiple domains across 
a broadband data network, comprising the steps of: checking 
a called number translation table at an edge node in the 
broadband data network which receives an admission 
request for the call to determine whether an address of a 
destination node to serve the called number is known; if the 
address is known, setting up an egress of the call from the 
broadband network; if the address is not known, formulating 
a query message at the edge node to determine the address 
of a destination node that serves the called number; and 
forwarding the query message to at least one predetermined 
node in the broadband data network to request a translation 
of the called number to determine the address of the desti- 
nation node; and for a predefined number of hops, forward- 
ing the query message to at least one other node if a node 
receiving the query does not possess information to enable 
the translation. 

In accordance with a further aspect of the invention there 
is provided a messaging protocol for called number address 
resolution in a broadband data network adapted to transfer 
synchronous transfer mode (STM) calls between synchro- 
nous transfer mode (STM) switches, comprising: a message 
header portion that contains fixed length fields for manda- 
tory information common to all messages; and a message 
content portion that contains a variable number of content 
objects, each content object including a content type 
indicator, a length indicator and content data. 

The invention therefore provides a method of address 
resolution and a messaging protocol for address resolution 
which facilitates the transfer of STM calls through multiple 
domains in a broadband data network, such as an ATM or an 
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FIG. 5 is a schematic diagram of the processing of an 

nodes are preferably organized in domains which consist of inter-domain request for gateway translation entries using 

a collection of edge nodes in the broadband data network the messaging protocol in accordance with the invention; 

that are equipped to accept STM call admission requests, FIG. 6 is a schematic diagram illustrating a procedure for 

each edge node being equipped with a voice interface 5 reverse switched virtual circuit setup using the methods and 

control unit described in applicant's U.S. Pat. No. 6,195, message protocol in accordance with the invention; and 

714, entitled SYSTEM FOR TRANSFERRING STM PTr - . a . f ov . 

CALLS THROUGH ATM NETWORK BY CONVERTING J£L%£££^£F"" & 

THE STM CALLS TO ATM AND VICE VERSA AT THE S piu^um* mjuwii 

EDGE NODES OF ATM NETWORK. The specification of 10 DETAILED DESCRIPTION OF THE 

that application is incorporated herein by reference in its PREFERRED EMBODIMENT 
entirety. The collection of edge nodes are logically fully 

meshed by control virtual circuits for call control and This invention relates to the organization of mulU-service 

address resolution message forwarding if the broadband ^ " a transport backbone for voice and 

network is an ATM network. 15 V010c data caUs whlch °ngmate and terminate in a switched 

. it . £ tl _ „ , ... - 4 . telephone network. In accordance with the invention, edge 

In the description of the preferred embodiments of the n f ... • , • ~ w •„ a™* > T 

, . , K - „ J . , . . „ node with voice interfaces in multi-service ATM networks 

invention which follows, reference is made principally to u - , uiu. . ♦ i r a 

A _. . . ., 1 , r r*4L M „ which serve as backbone transport networks for voice and 

ATM networks which are currently used for STM cal yoice da , a ^ zed £ donjajns 

transfer. It will be understood by those skilled in the art that Each domajn consis| / of a collection of ed nodes ad ted 

the principles described may be applied with minimal revi- 20 , o ^ hronous transfer mode admission £ slS) 

sion to IP networks, as will be described below in more , ne e(J nodes bej , ica „ M meshed b contro , 

detail. Each domain includes at least one gateway switch. A virlua , fof ^ conlro , ^ addfess mes . 

gateway switch is a broadband edge node having a known ^ Messaging may be accomplished using a sin g le 

path to at least one peer gateway m an adjacent domain. ^ of ^ den , virtua , dreuils be 

Gateway switches serve as voice call control paths between » ^ to cM contro , an£) addfess resolution m . 

domains and are preferably enabled to maintain address m ^ invention ^ methods and a m m £ 

resolution information respecting other domains in the ^ for caUed number addfess resolution across m ^ ti . 

broadband data network. This imposes a hierarchy on the domains oyer an ^ netWQrk , n a fcrred method fa 

voice edge nodes connected to the broadband data network, accordaDC6 ^ , hc inv6Dtion> „,„ setup time is reduced by 

although the broadband data network is not aware of the 3" usi a techni hereinafter referr ; d t0 as « reverse 

hierarchy and not encumbered by it. switched viftual circuit „ (svc) se , up fa whJch Jn §vc , 0 

The methods and the messaging protocol in accordance S6rvc , n6 ca ll is set up from a destination node to an 

with the invention therefore permit automatic maintenance origination node in the ATM network using native ATM 

of routing tables to enable address resolution for STM calls $vC setup methods. Cached SVC's may also be used to 

admitted to a broadband data network without imposing further improve call setup response. A messaging protocol 

non-native signaling protocols on the broadband data net- defines message units which include a message header 

work or integrating a common channel signaling network port i on that contains fixed length fields for mandatory 

into the broadband data network. Thus, STM traffic can be information common to all messages and a message content 

rapidly and economically transferred to broadband data portion tnat contains a variable number of content objects, 

facilities with a minimum of preparation and consequently a eacn content object including a content type indicator, a 

minimum of expense. length indicator and content data. 

In the case of an IP network connectionless service is used 

for call control and address resolution routing. Network Architecture 

45 FIG. 1 shows a schematic diagram of a multi-service ATM 

BRIEF DESCRIPTION OF THE DRAWINGS network 10 adapted t0 serve as a backbone transport net . 

The invention will now be further explained by way of work for synchronous transfer mode (STM) calls which 

example only and with reference to the following drawings originate and terminate in a switched telephone network, 

wherein* ^ ne schematic diagram shown in FIG. 1 illustrates the ATM 

i * * j * r irmj . i a * a 50 nodes 12 and their transfer links 14. Also illustrated are the 

FIG. 1 is a schematic diagram of an ATM network adapted JU . . , . . , , ^ , . , . . , , 

, . . , r , c j time division multiplex switches 16 which originate and 

to receive admission requests lor synchronous transfer mode t . . , . „ . i_ j . i u *, i 

... . . 4 j «, • / • » j * i u terminate voice data calls in switched telephone networks, 

calls which originate and terminate in a switched telephone ™ .. . t . . t , tl f . . . 

■ .i. a-^x* i l ■ a • i f * c The lines and trunks associated with the time division 

network, the ATM network being organized in a plurality of ... . , A , t . _ . „ . . 

domains" multiplex switches 16 are not shown. The time division 

' 55 multiplex switches are labelled as service switching points 

FIG. la shows a preferred structure for message signal «sSPs". They are numbered as SSP-A1 through SSP-DS, 

units for a messaging protocol in accordance with the ^ Am nodes u are labellcd S . A1 through s . D4t 

invention, ^ e ATM network 10 shown in FIG. 1 is organized into 

FIGS. 2b and 2c show a table illustrating a preferred four domains schematically indicated by broken outlines, 

message categories, types and the purpose and content of 60 n& domains 18a through IHd are, as explained above, 

each message type using the messaging protocol for address collections of edge nodes adapted to serve voice and voice 

resolution in accordance with the invention; data call admission requests. The edge nodes in each domain 

FIG. 3 is a schematic diagram showing an intra-domain are logically fully meshed by control virtual circuits for call 

initialization procedure in accordance with the protocol control and address resolution signaling. Each domain may, 

shown in FIGS. 2b and 2c; 55 for example, be associated with a specific carrier network 

FIG. 4 is a schematic diagram showing the results of the such as a local exchange carrier (LEC) or an interexchange 

initialization process illustrated in FIG. 3; carrier (IEC). A large carrier network may be organized into 
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ScVcial uuuiania in uidcr Lu fauilnaie manage mem and 
address resolution. The multi-service ATM network 10 may 
be owned and operated by a single service provider or by a 
plurality of service providers, as is well understood in the 
art. 

As described in applicant's co-pending patent application 
referenced above, each of the ATM nodes 12 which serves 
as an edge node in the ATM network for voice and voice data 
calls is associated with a time division multiplex peripheral 
20 (TP), hereinafter referred to as a TDM peripheral 20. The 
TDM peripheral 20 terminates STM trunks 22 and converts 
STM data to ATM cells and vice versa. Each ATM node 12 
that serves as an edge node to a switched telephone network 
also includes a voice interface control unit (not illustrated), 
as also explained in applicant's co-pending patent applica- 
tion. For the purposes of the discussion which follows, it will 
be assumed that the voice interface control unit is incorpo- 
rated in a switch control element 24 of the ATM switches 12, 
and the reference 24 will be used to refer to both the switch 
control element 24 of the ATM nodes 12 and the voice 
interface control unit 24. 

The voice interface control units 24 of the nodes 12 in 
each domain ISa-lSd may be fully physically meshed as 
shown in domain 18c or simply logically meshed with 
control virtual circuits as shown in domain I8d. In domain 
lSd, ATM nodes S-Dl and S-D3 have a logical direct control 
virtual circuit that depends on physical transport links which 
traverse node S-D2. Also, each domain \Sa~d includes at 
least one node designated as a gateway to at least one other 
domain. Gateway nodes have control virtual circuits estab- 
lished with peer gateway nodes in neighbouring domains. 
Each domain includes at least one gateway node. For 
example, domain 18a includes two gateway nodes S-A3 and 
S-A4. S-A3 has a control virtual circuit established with its 
peer S-D4. Gateway node S-A4 has a control virtual circuit 
established with its peer gateway node S-Bl in domain 18fc. 
Domain 18c likewise includes two gateway nodes S-C2 and 
S-C5 which have control virtual circuits respectively estab- 
lished with gateway node S-D4 in domain ISd and gateway 
node S-Bl in domain 18/?. 

It will be understood by those skilled in the art that the 
domains shown in FIG. 1 are exemplary only and do not 
necessarily represent the organization or partitioning of a 
real network. 

Messaging Protocol 

The method of address resolution in accordance with the 
invention uses a messaging protocol for dialled number 
(DN) address resolution in the multiple domain ATM net- 
work 10. The messaging protocol defines messaging signal 
units 26. The preferred structure of the messaging signal unit 
26 is shown in FIG. 2a. The messaging signal unit 26 
includes a messaging header portion 28 that contains fixed 
length fields for mandatory information common to all 
messages, and a message content portion 30 that contains a 
variable number of content objects 32, each content object 
32 includes a content type indicator, a content length indi- 
cator and content data. The preferred implementation of the 
messaging protocol defines six different message types. 
Each message is further categorized as a REQUEST or a 
RESPONSE, as will be described below with reference to 
FIGS. 2b and 2c in which the six types of messages defined 
by the preferred embodiment of the messaging protocol are 
described in more detail. 

In general, the six types of messages are: 
1. Intra-domain initialization used to populate all edge 
nodes in the same domain with dialled number prefixes 
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(DKs) served by the domain. RESPONSE to type 1 mes- 
sages is mandatory. 

2. Intra-domain updates to advise all edge nodes of a 
change(s) in DNs served by an edge node in the domain. A 

5 RESPONSE is expected but the RESPONSE may be void of 
content. 

3. Translation entry query for information respecting the 
identity of a node that serves a particular DN. The protocol 
may permit any node possessing the information to respond 

10 to a type 3 message or responses may be restricted to 
gateway nodes in the domain of the node that serves the DN. 
Also used for inter-domain translation entry exchanges used 
to provide gateway nodes with DN routing information. 
Type 3 messages are sent and received only by gateway 

15 nodes. 

4. Inter-domain messages to notify nodes in other 
domains of DN changes or translation entry changes. 
Response is expected but the response may be void of 

2Q content. 

5. Next-hop routing REQUEST with reverse SVC setup to 
obtain a translation entry for a specific DN and to concur- 
rently set up a call path from the destination node to the 
originating node which launched the query. A translation 

25 RESPONSE is mandatory if a destination node receives the 
REQUEST message 

6. Next-hop routing request with reverse SVC setup 
without a translation query. Translation query response data 
is not included in a RESPONSE to a type 6 message. 

30 Alternatively, a type 5 message can be used to request 
reverse SVC setup without a translation query, in which case 
a translation query object is not included in the message. If 
this type 5 message format is used for reverse SVC setup, the 
type 6 is not required. 

35 The remaining fields in the message header include: 

A sequence number generated by the voice interface 
control unit 24 for the purposes of associating RESPONSES 
with a REQUEST. 
A source node identification in the form of a source node 

40 address prefix and a point code assigned to the voice 
interface control unit 24 which originates the message; 

A source node address type to distinguish the addressing 
system used by the backbone network which may be, for 

45 example, ASEA, E.164 or IP addressing; 

A destination address which includes the address prefix 
and the point code of the voice interface control unit 24 of 
the destination node. For type 3, type 5 and type 6 messages, 
a destination is unknown and the destination address field is 

50 null filled. Those messages are normally forwarded to the 
domain's gateway node(s), which preferably maintain next- 
hop resolution routing tables that permit the message to be 
forwarded toward the destination node, as will be explained 
below in more detail; 

55 A destination node address type to distinguish the 
addressing system used by the backbone network which may 
be, for example, ASEA, E.164 or IP addressing; 

A "time to live" (n L) field which stores an integer 
assigned for each message type by a network manager at a 

60 voice interface control unit 24. When a message is formu- 
lated by a voice interface control unit 24 of a node 12, the 
voice interface control unit 24 inserts the default TTL into 
the message header. Each recipient node examines the TTL. 
If the TTL is greater than one, the recipient node may 

65 respond to the message or forward the message as appro- 
priate. If the TTL is one, the recipient node may respond to 
the message but may not forward the message. If the TIL is 
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without responding or forwarding. Before forwarding a 
message, each node subtracts one from the value of the TTL 
field; and 

A message length field to indicate a total length of the 5 
message, including the message content portion. 

As explained above, the message content portion contains 
a variable number of content objects 32. Each content object 
32 includes a content type indicator. In accordance with the 
preferred embodiment of the invention, defined content 10 
types include: 

a) local DN list which may be included in any REQUEST 
or RESPONSE message except type 6 messages to 
provide other nodes with a list of dialled number 
prefixes served by the node originating the REQUEST 15 
or RESPONSE message; 

b) domain DN list which may be included in message 
types 3, 4, 5 or 6 to provide nodes in another domain 
with all DNs served by a source domain. The domain „ 

20 

DN list does not provide destination addresses associ- 
ated with the DNs in the list; 

c) group list for gateway domain DNs which may be 
included in message types 3 or 4 to provide gateway 
nodes in other domains with a list of DNs served by the 25 
source domain as well as the point code and the AESA 
address of the gateway node for the domain. A group 
content object can be added by each gateway node that 
receives a type 3 or 4 message; 

d) translation query data which is included in a 30 
REQUEST message and contains a specific DN for 
which a translation is required. Translation query data 

is also included in a RESPONSE message and then 
contains the ASEA address and point code of a voice 
interface control unit that serves the DN; 35 

e) point code stack data for which two content type 
identifiers exist. The point code stack data is used to 
prevent message loop-back and to provide message 
path data for domain gateway nodes. The point code 
stack includes the point code of each voice interface 40 
control unit traversed by a REQUEST message. In a 
RESPONSE message the point code stack data is 
copied to a new content object hereinafter referred to as 
the "original PC stack" which is assigned the second 
content type identifier for PC stack content objects. The 45 
point code stack is used to route a RESPONSE message 
back to the voice interface control unit that originated 
the REQUEST message and the original point code 
stack provides a record of the entire path traversed by 
the REQUEST and RESPONSE messages; 50 

f) SVC setup request data which includes an originating 
node ASEA prefix and point code as well as a VCCI 
and other data such as a traffic contract, called party 
address, QOS, etc. to be used to set up the SVC by the 
destination node receiving the SVC request; and 55 

g) a failure indication may also be included in 
RESPONSE messages to indicate a failure condition. 
For example, if an SVC request cannot be satisfied a 
failure indication will be returned. 

The message structure permits the addition of any number 60 
of other content object types, as a need arises. 

FIGS. 2b and 2c provide examples of the six types of 
messages for address resolution. As explained above, mes- 
sage type 1 is used forintra-domain initialization to populate 
all nodes in the same domain lHa-lSd with dialled numbers 65 
(DNs) served by a node requesting initialization or respond- 
ing to a type 1 initialization request. 



hi accordance with protocol, each address resolution 
message is identified as a REQUEST or a RESPONSE 
message. The source ASEA address (Al) and the source 
point code (PC) (PI) of the requesting voice interface 
control unit 24 is provided to permit responding voice 
interface control units 24 to address the RESPONSE. The 
destination address (Ax, Px) shown in FIG. 2b is changed as 
a copy of the message is sent to each other voice interface 
control units 24 in the domain. Since the request is for 
intra-domain initialization, the ATM node 12 incorporates a 
content object 32 in the message which includes a local DN 
list. The local DN list includes all dialled number prefixes 
(DNs) that are served by the requesting voice interface 
control unit 24. The DNs in the local DN list are truncated 
to the minimum distinguishing number of digits. For 
example, if a voice interface control unit 24 serves an entire 
area code, the DN is truncated to the Number Plan Area 
(NPA) or the country code and area code for terminations 
outside North America. If, however, the voice interface 
control unit 24 serves only selected exchanges of an area 
code, the NPA plus exchange codes are included in the local 
DN list. 

Address Resolution 

FIG. 3 is a schematic diagram illustrating initialization 
messages sent in domain 18c (FIG. 1) when the voice 
interface control unit associated with ATM edge node S-C6 
sends initialization messages of type 1 or type 2. For 
example, if the edge node S-C6 is being brought into service 
to connect SSP-C3 or SSP-C2 to the ATM network 10, the 
associated voice interface control unit 24 is configured with 
permanent virtual circuits dedicated to control messaging. 
On initialization, the voice interface control unit 24 of node 
S-C6 formulates a type 1 REQUEST messages (FIG. 2b) 
which it sends to each of the nodes in its domain to which 
it has a configured control virtual circuit. Messages are 
therefore sent to nodes S-C2; S-C3; S-C4; and S-C5. The 
message path is indicated by the bold black lines 34 shown 
in FIG. 3. Each REQUEST message 34 includes the local 
DN list of node S-C6 to provide peer nodes in the domain 
with the DNs served by the node S-C6. On receipt of the 
REQUEST message of type 1, the receiving nodes respond 
with a RESPONSE message of type 1 (FIG. 2b) in which the 
responding voice interface control units 24 provide their 
corresponding local DN list. The RESPONSE message path 
36 is indicated by the bold dashed lines in FIG. 3. Type 2 
REQUEST messages and type 2 RESPONSE messages are 
sent by the same paths for updating a change in the local DN 
list. 

FIG. 4 schematically illustrates the effects of a type 1 
REQUEST and a type 1 RESPONSE message exchange. As 
is apparent, when the REQUEST is formulated, the request- 
ing node translation table 38 includes only the local DN list. 
After receiving the REQUEST, the receiving node "S6" adds 
the DN list of the requesting node "SI" to its translation 
table 40 and responds with its local DN list. On receipt of the 
RESPONSE message, node SI adds the local DN list of 
node S6 to its translation table 38 as shown in FIG. 4. 
Consequently, the voice interface control unit 24 associated 
with each node 12 in each domain maintains a translation 
table which includes all DNs served by the domain. When- 
ever a node administrator changes a translation table or a 
domain administrator adds a new node or a new voice 
interface control unit 24 to the domain, the results are 
flooded to other peers in the domain using type 1 or 2 
messages, so that the translation tables are automatically 
maintained. Therefore, an SVC can be set up immediately by 
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' any STM call which originates auu can aisu be configured 10 discard a REQUEST message tor 
terminates on SSPs served by ATM nodes 12 within the certain DNs. This option may be used by network admin- 
same domain. This enables rapid intra-domain call process- istration to control unnecessary flooding. When a peer 
ing. Call processing speed may be further improved using gateway node receives the type 3 REQUEST message, it 
switched virtual circuits as described in applicant's 5 checks its translation tables to determine whether it has 
co-pending patent application entitled "METHOD AND knowledge of the DN and, if so, responds with a type 3 

^^TVk.^^^^ 1 ^ CIR " RESPONSE (FIG. 2c). Tliis chain continues until a gateway 

™ ^ NETWORK", which was filed - on Apr. node has ^ destinalion Qode lQ &Qryc \ Q DN X 

2, 1998, and has now issued as U.S Pat. No. 6,275,493, the M ±e voice comrol unit 24 associated with each 

specification of which is incorporated herein by reference in w flode ^ message> {{ ch£cks the ^ M 

its entirety. above ^ {f lhe ig ^ y() ice imerf ace control umt 24 

Although inter-domain calls may be routed directly, call can respond to lhe message 5ul not forward it Before a 
admission requests will be received by the voice interface message is forwardedf the voice mterface control unit 2 4 
control unit 24 associated with DNs served by other deducts one from and adds ils point code t0 the pc 
domains. The voice interface control units 24 receiving such 15 stack If {is ^ ^ ^ already in thc pc stack> thc 
requests require a mechanism to resolve thc address of a REQUEST message is discarded to prevent message loop- 
destination node which serves the DN. Three solutions are mg Whcn a voicc mter f acc control unit 24 node having 
described below. knowledge of the destination node to serve the call receives 

In a first solution, a next-hop address resolution method is tn e message, it prepares a type 3 response message which it 

described in which a translation entry REQUEST message is 2 o returns to the requesting voice interface control unit 24 using 

sent through the network to determine the address of the the data in the PC stack to route the message back to the 

destination node. In a second of the solutions, a translation or i g i ni Th e PC stack is a last-in-first-out (LIFO) pop-up 

entry REQUEST message is sent along with an SVC request sta ck. Consequently, the response message will transverse a 

to enable reverse SVC setup from the destination node in reverse order of the point codes in the stack. When the voice 

order to facilitate call processing. In the first and second 2 s interface control unit 24 of the gateway in the originating 

solutions, the address of the voice interface control unit 24 domain receives the response message, it passes the message 

associated with the destination node that serves the called on l0 me voice interface control unit 24 associated with the 

number is stored at the originating voice interface control originating node, and records the sequence ID from the 

unit 24 and may be flooded to its peers in the same domain. message and the destination address of the RESPONSE 

In networks where the translation tables become too large, 30 message. If a subsequent RESPONSE message with the 

however, the preferred solution is to use next-hop routing same sequence ID and destination address is received, that 

with reverse SVC setup without a translation entry query. message is discarded. As the RESPONSE message is passed 

Each of these solutions are described below in some detail. to the originating node through the various gateway 

When a voice interface control unit 24 receives an STM nodes, each gateway node may enter the translation query 

call admission request, if the voice interface control unit 24 35 response data into its own translation tables. Each gateway 

does not have a record in its DN translation table 38, 40 node may also append its local DN list as a content object 

(FIG. 3) to determine an ATM destination node to service the to the message. Each gateway may further optionally flood 

call, the voice interface control unit 24 may use a type 3 the translation query data to all other edge nodes in its 

REQUEST message to query other network nodes for the domain using REQUEST type 2. If such flooding is 

address. Before sending a type 3 request message, the voice 40 practiced, it is preferable that a message delay clock be 

interface control unit 24 at the originating node may be implemented in each voice interface control unit 24. The 

programmed to perform one of two options. The first option purpose of the delay clock is to prevent flooding for a 

is to simply release the call back to the PSTN on the theory predetermined period of time subsequent to a last flooding 

that locating the destination node will take too long to serve by the same voice interface control unit 24. This helps 

the call within an acceptable call setup delay. The PSTN can 45 ensure that the control virtual circuits are not overloaded 

then route the call through its STM facilities. The second with flooding messages. 

option is to set a time-out clock when the REQUEST „„ , . „ . . . 

message is formulated. If the time-out clock expires before . When a «**«iuent call to the same DN is received at the 

a RESPONSE is received, the call is released back to the originating edge node or any otoer node to which the query 

PSTN which routes the call through its STM facilities. 50 * ata was fl A °^ ed ' an *™ SVC ca ° * x \ u ? t0 

. ..... maimer 1 /mo destination ATM node which is now in the translation table. 

n e.tner instance, a KtuuKj message oi type J ^iu. Furlhermore : f me 

voice interface control unit 24 associated 

26) ,s formulated, and forwarded to the gateway node of the ^ each node fc med l0 &{OK the nex ,. h 

domain. If the domain has more than one gateway node, a fo * D > , sup m s ca „ be ^ 

type 3 message may be sent to each gateway, unless other- jn ATM ^ {Q ^ des[ination voice comrol uni , 

wise instructed by preconngured information. On receipt of 55 . . c , . c r™^* 

4 , . ~ ' \, • • . * t 1 -m 24 to permit the set up of an egress trunk path from the TDM 

the type 3 message, the voice mterface control umt 24 at the . £ . * A iL 4 r iL *i T ™ . . r . . iL 

A Jr .Li-.. 1 . ■ ...... • peripheral 20 that serves the DN. This minimizes the amount 

gateway node checks its translation table to determine r « <• • j * .u u 1 * i- 

& . t . -v. . . . , 4 . t . . - of configuration required in the common channel signaling 

whether 1. has knowledge of the termination node or the DN network B for voice 4 interface conlrol unils 34, since call 

in question. If it cannot locate the DN in its translation 4 . , , . 4 it _ , 4| _ A ™ t . , 

.? . . .... j . .1. control data is sent through the ATM network. 

tables, the gateway node adds its point code to the content 60 ° 

object containing the PC stack, subtracts one from the TTL In order to conserve memory required for next -hop reso- 

and forwards the REQUEST message to each peer in adja- lution routing tables which are used to route call control and 

cent domains with which it has a control virtual circuit address resolution massages, the voice interface control 

established. The gateway can also be configured with the units at gateway switches need only save a next-hop address 

next-hop routing resolution table respecting where to send a 65 for any DN that is not served within that gateway's domain. 

REQUEST message for a given DN, rather than sending a A preferred structure for such a table is shown below in 

REQUEST message to every adjacent domain. A gateway Table 1. 
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TABLE I 



Gateway Next-Hop Resolution Routing Table 
DN Next-Hop AESA Next- Hop PC Control VC 
913-547 Al PI VCx 



In order to facilitate call control and address resolution 
message routing, an initialization procedure similar to that 
described above with reference to message types 1 and 2 can 
be used to permit gateway nodes to build their gateway 
next-hop resolution routing tables. Message type 3 is used 
for that purpose. As shown in FIG. 2c, a type 3 message is 
used for inter-domain request for next-hop resolution table 
entries. FIG. 5 schematically illustrates a type 3 message 
exchange which originates at the gateway node S-A3 which, 
for the sake of example, was recently designated a gateway 
node. In the message exchange shown in FIG. 5, the voice 
interface control unit 24 associated with gateway S-A3 
formulates a type 3 REQUEST message which includes a 
content object of the type "group (gateway AESA, point 
code; domain DN list)", and forwards the message to its peer 
at S-D4. The gateway node S-A3 also forwards a copy of the 
message to its peer at S-A4 in the same domain. Each type 
3 message has a TTL=4. As shown in FIG. 5, the message 
received by gateway S-A4 is subsequently forwarded to 
gateway S-Bl, 

Before forwarding the message, the gateway S-A4 exam- 
ines the content objects for any information which it does 
not possess in its routing tables. Since the message origi- 
nated in its own domain, it has all of the domain DN list 
owned by gateway S-A3 in its routing tables. Consequently, 
it simply adds its point code to the PC stack, adds a content 
object with its own "group (gateway ASEA, point code; 
domain DN list)", subtracts one from TTL and forwards the 
message. On receipt of the message, gateway S-Bl inspects 
the content objects of the message. Assume that gateway 
S-Bl already knows the domain DN list of gateway S-A4 
and it is the shortest path to the domain of S-A4. Gateway 
S-Bl likewise simply adds a content object to the message 
with its domain DN list, adds its point code to the PC stack, 
subtracts one from the TTL and forwards the message to 
S-C5. For the sake of example, it is assumed that gateway 
S-C5 does not know the domain DN list of domain "A", 
When gateway S-C5 examines the content objects, it there- 
fore copies the contents of the object added by gateway 
S-A4 after inspecting each of the content objects. Gateway 
S-C5 supplements the copied domain DN list with the next 
hop indicated as domain gateway S-Bl and a path length of 
two hops because gateway S-A4 is two hops away on this 
path. S-A4 was selected because it is two hops away, while 
S-A3 is three hops away. S-C5 then adds a content object 
with its own domain DN list, adds its point code to the 
original PC stack, subtracts one from TTL and forwards the 
message to S-C2. On receipt of the message, S-C2 inspects 
the content objects and adds the domain list of S-Bl and 
S-A4 to its next-hop resolution table because those DNs 
were, for the sake of example, unknown to that gateway. 
Gateway S-C2 with TTL equal to zero converts the 
REQUEST to a RESPONSE and returns the RESPONSE 
along the reverse path of the REQUEST as described above. 
In the RESPONSE message a record of the entire path is 
kept in the original PC stack and the PC stack is used to route 
the RESPONSE message along the same path back to the 
originating node. Each gateway node receiving the 



RESPONSE message examines the content objects attached 
to the RESPONSE to determine if they contain a new 
domain DN list or a shorter path for a known domain DN list 
in its next-hop resolution routing table. If so, it will update 
the table. As a result of this process, the next-hop resolution 
routing table in originating node S-A3 is updated with 
domain DN list information to permit it to route calls to DNs 
served by any of domains B, C and D using a shortest call 
control messaging path. 

The REQUEST message sent by S-A3 to S-D4 is for- 
warded to S-C2, S-C5 and S-Bl in a similar procedure. Each 
gateway on the path updates its next-hop resolution routing 
table with any new domain DN lists or any shorter path. For 
DNs served by the domain 186 (FIG. 1), the gateway S-A3 
determines, by inspecting the RESPONSE messages, that 
the preferred next-hop to the gateway S-Bl is through its 
peer gateway S-A4 whereas control messages for calls 
served by domain 18c are best routed to node S-C2 via node 
S-D4. The DNs received from gateway S-C2 are therefore 
stored in Table I with the next-hop address being the point 
code and AESA prefix of the gateway node S-D4. In 
domains A and C which have two gateways each, the 
gateways (S-C2, S-CS, for example) may be programmed to 
flood domain DN-list information to all other voice edge 
nodes in the domain to permit the voice interface control 
nodes 24 to build their DN routing tables to include shortest 
hop routes. Alternatively, system administrators may con- 
figure each voice edge node to send certain inter-domain call 
control and address resolution messages to a specific gate- 
way. 

Reverse SVC Setup 

Once the next-hop address resolution table is built, it can 
be used to enable reverse SVC setup. Therefore, in order to 
ensure that a call admission request can be served with an 
acceptable delay, the preferred method of address resolution 
is to use a REQUEST message of type 5 or type 6 (FIG. 2c). 
Type 5 REQUEST messages include a content object which 
instructs reverse SVC setup from the destination node. FIG. 
6 illustrates a signaling and SVC setup sequence using a 
REQUEST message of type 5. As shown in FIG. 6, a called 
admission request is received from SSP-A4 by the voice 
interface control unit 24 associated with ATM node S-A2. 
The voice interface control unit 24 associated with the ATM 
node S-A2 cannot locate the DN in its translation table. Its 
control program is instructed to formulate a type 5 
REQUEST message under those circumstances. A type 5 
REQUEST is therefore formulated and forwarded to the 
gateway node S-A3. The voice interface control unit at S-A3 
consults its gateway routing table (Table 1) and determines 
that the next-hop for the dialled number is the gateway node 
S-D4. The voice interface control unit 24 at S-D4 consults 
its gateway routing table and determines that the next-hop is 
gateway node S-C2. The voice interface control unit at the 
gateway node S-C2 has knowledge of the terminating node 
that serves the DN because the DN is served by its domain. 
It consults its translation table and determines that the 
destination node is S-C6. Since all nodes in the domain are 
logically fully meshed, the gateway node S-C2 has a virtual 
control circuit to the destination node S-C6 and forwards the 
type 5 message to that node. On receipt of the message, the 
call interface control unit at destination node S-C6 examines 
the content objects and extracts the SVC request which 
includes the origination node address and a VCCI to be used 
for setting up an SVC to serve the call. The node S-C6 
therefore sets up a SVC using ATM routing methods which 
select the shortest path through the originating node. The 
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o v \^ us represented oy ine neavy oiacK line w snown in MU. 
6. As may be seen, the SVC traverses the nodes S-Cl and 
S-A3 which is the shortest path to the originating node S-A2. 
On receipt of a CONNECT confirmation from S-A2 advis- 
ing the destination node S-C6 that the SVC setup is 
complete, the destination node S-C6 forwards an IAM 
message to the destination PSTN. When the destination node 
S-C6 receives an ACM and an ANM from the destination 
PSTN, it returns a response message via the same path 42 
indicated by the heavy dashed line to the voice interface 
control unit 24 at the node S-A2. 

In accordance with this protocol, the REQUEST and 
RESPONSE messages replace corresponding ISUP SS7 
messages. The REQUEST message replaces the ISUP IAM. 

The ISUP IAM message can be encapsulated in a content 
object of the REQUEST message and sent to the destination 
voice interface control unit 24. The RESPONSE message 
replaces the ISUP ACM and ANM messages. Similarly, the 
ISUP ACM and ANM messages can be encapsulated in 
content objects of the RESPONSE message. Thus signaling 
load in the common channel signaling network is reduced 
and the number of signaling messages is minimized. FIG. 7 
is a schematic diagram of the messages exchanged during 
the reverse SVC setup shown in FIG. 6. 

The RESPONSE message shown in FIG. 6, includes DN 
translation data which may be stored by the originating node 
S-A2 and in intervening nodes (S-A3; S-D4). In very large 
networks, however, saving translation data for every DN 
could make translation tables too large and too complex for 
efficient operation. 

The invention therefore provides a request message of 
type 6 which is used for next-hop routing REQUESTS with 
reverse SVC setup, without a translation entry query. The 
message type 6 permits call setups with reverse svc setup, as 
shown in FIGS. 6 and 7, without returning translation query 
data. In accordance with this solution, each voice interface 
control unit at edge nodes in each domain knows and 
maintains routing tables for its own DNs. Gateway nodes 
S-A3, S-A4, S-Bl, S-C2, S-C5 and S-D4 each maintain 
next-hop routing tables, (Table 1). Call completion is 
accomplished using REQUEST messages of type 6 in which 
SVCs are set up in reverse from the destination node. This 
permits efficient call setup while minimizing translation 
table size and ensuring automated translation table mainte- 
nance. Call setup performance can be further improved by 
using cached SVCs for the reverse SVC setup to further 
improve SVC setup time. 

Although the preferred embodiment of the invention has 
been described with reference to an ATM network as the 
broadband backbone for transferring voice and voice data 
calls, the methods of address resolution and call control 
messaging described above are equally applicable to the use 
of an IP network for the same purpose. 

If the methods and apparatus are used for the transfer of 
voice and/or voice data over IP, each voice interface control 
unit is assigned an address which includes an IP address and 
a point code. The address field in all call control and address 
resolution messages is set to indicate the address type as 
"IP", as described above. The control VCs between voice 
interface control units are not currently supported by IP 
protocol, so REQUEST and RESPONSE messages, as well 
as call control messages are sent as connectionless service IP 
packets. Since all IP services are currently connectionless, 
the method of reverse SVC setup is not used. Nonetheless, 
the next-hop resolution routing table is built and maintained 
to indicate the next-hop IP address of a gateway voice 
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interface control unit 24 to facilitate call setup using a 
shortest path. Call control messages are forwarded using that 
shortest path to a destination voice interface control unit to 
enable call egress setup to the PSTN. 

If the IP network supports such protocols as RSVP or 
MPLS/LDP, which are known in the art, a path may be set 
up for the call. In that case, IP path setup can be done in a 
similar way to the reverse SVC setup described above. 
Alternatively, the call setup in the destination PSTN may be 
done before the path setup is completed in the IP network. 
On receipt of the REQUEST message, the destination IP 
edge node may immediately forward an IAM to the desti- 
nation PSTN. After ACM and ANM messages are received 
from the destination PSTN, a RESPONSE message may be 
returned to the originating IP edge node to indicate the IP 
address of the destination edge node. Before the path is 
available, voice packets are forwarded using connectionless 
packets in the IP network. 

The embodiments of the invention described above are 
exemplary only of implementations of the methods and 
messaging protocol in accordance with the invention. 
Changes and modifications of the embodiments described 
will no doubt become apparent to those skilled in the art. The 
invention is therefore intended to be limited solely by the 
scope of the appended claims. 

We claim: 

1. A method of address resolution for the transfer of 
synchronous transfer mode (STM) calls through multiple 
domains in an ATM network, comprising the steps of: 

checking a called number translation table at an edge node 
in the ATM network which receives an admission 
request for the call to determine whether an address of 
an ATM destination node to serve the called number is 
known; 

if the address is known, setting up a switched virtual 
circuit for transferring the call through the ATM net- 
work; 

if the address is not known, formulating a query message 
at the edge node to determine the address of an ATM 
destination node that serves the called number; 

forwarding the query message to at least one gateway 
node in a domain of the edge node in the ATM network, 
to request a translation of the called number to deter- 
mine the address of the ATM destination node; 

for a predefined number of hops, forwarding the query 
message to at least one other ATM node if a node 
receiving the query docs not possess information to 
enable the translation; and 

starting a time-out clock when the query message is 
forwarded, and releasing the call back to STM facilities 
if a response to the query message is not received 
before the time-out clock has expired. 

2. A method as claimed in claim 1 wherein the domains 
comprise a collection of edge nodes adapted to serve STM 
call admission requests, the edge nodes being logically fully 
meshed by control virtual circuits for call control and 
address resolution messaging. 

3. A method as claimed in claim 2 wherein the gateway 
node has ATM virtual circuit established control messaging 
with a peer gateway node in an adjacent domain of the ATM 
network. 

4. A method as claimed in claim 3 wherein the query 
message is sent to each gateway node in the domain of the 
edge node. 

5. A method as claimed in claim 4 wherein the gateway 
node has a next-hop resolution routing table which provides 
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a next liop node iu a luuic for ilic eaiieu number and ihe 20. A method as claimed in claim iy wherein the edge 

gateway node forwards the query message to the next hop node floods the called number, the PC and the ASEA address 

node if the called number is located in the routing table. of the destination ATM node that serves the called number 

6. The method as claimed in claim 5 wherein the next-hop to all other nodes in the same domain. 

resolution routing table is automatically maintained by the 5 21. A method of address resolution for the transfer of 

gateway node which sends address resolution messages to synchronous transfer mode (STM) calls through multiple 

neighbouring gateway nodes to request information used to domams in an IP network, comprising the steps of: 

maintain data in the table. L1 . „ , , , ■ , , , 

7. The method as claimed in claim 6 wherein the gateway checking a called number translate table at an edge node 
node floods the next-hop resolution routing table data to all in * th f IP n ^ 01 } whl ? h rcc f 1V ( CS an admission request 
edge nodes in the ATM network. for the cal1 to determine whether an address of an IP 

8. A method as claimed in claim 5 wherein on receipt of destination node to serve the called number is known; 
the query message at a gateway node in a domain that serves if the address is known, sending IP packets to the desti- 
the called number, the gateway node in that domain forwards nation node to set up egress of the call from the 
the query message to the destination ATM node that serves destination node to the STM network; 

the called number. . 15 if the address is not known, formulating a query message 

9. A method as claimed in claim 8 wherein the query al the ^ Qode lQ delermifle me addfess of m {? 
message contains a switched virtual circui (SVC) setup deslination node that serves the called number; 
request and on receipt of the query message, the destination 

ATM node begins a backward setup of an SVC to the forwarding the query message to each gateway node in 

originating ATM edge node, the SVC being used for the call 20 *e domain of the edge node in the IP network to 

transfer. request a translation of the called number to determine 

10. A method as claimed in claim 9 wherein the SVC is tne address of the IP destination node; and 

set up by the ATM network using a shortest path method for for a predefined number of hops, forwarding the query 

SVC setup. message to at least one other IP node if a node receiving 

11. A method as claimed in claim 10 wherein the query 25 the query does not possess information to enable the 
message includes a point code (PC) stack which includes a translation. 

PC for each node traversed by the query message and the PC 22. A method as claimed in claim 21 wherein the gateway 

stack is used to route a response message from the destina- node has a next hop resolution routing table which provides 

tion ATM node to the originating ATM edge node. a next hop node in a route for the called number and the 

12. A method as claimed in claim 11 wherein the query 30 gateway node forwards the query message to the next hop 
message further includes a message type field. node if the called number is located in the routing table. 

13. A method as claimed in claim 12 wherein the message 23. A method as claimed in claim 22 wherein on receipt 
type field contains a value that indicates that a translation of the query message at a gateway node in a domain that 
response is to be provided in response to the query message serves the called number, the gateway node in that domain 
and the destination ATM node returns the translation 35 forwards the query message to the destination IP node that 
response to provide the ATM edge node with a PC and serves the called number. 

AESA address of the destination ATM node. 24. A method as claimed in claim 23 wherein the query 

14. A method as claimed in claim 13 wherein the called message includes a point code (PC) stack which includes a 
number is truncated to a minimum distinguishing number of PC for each node traversed by the query message and the PC 
digits before the translation response is returned by the 40 stack is used to route a response message from the destina- 
destination ATM node. tion IP node to the originating IP edge node. 

15. A method as claimed in claim 13 wherein each node 25. A method as claimed in claim 24 wherein the query 
in the PC stack which is traversed by the translation response message further includes a message type field. 

message records in its called number translation table the 26. A method as claimed in claim 25 wherein the message 

called number, PC and ASEA address of the ATM destina- 45 type field contains a value that indicates that a translation 

tion node that serves the called number. response is to be provided in response to the query message 

16. A method as claimed in claim 15 wherein after and the destination IP node returns the translation response 
recording the called number, PC and ASEA address of the to provide the IP edge node with a PC and IP address of the 
ATM destination node that serves the called number, each destination IP node. 

ATM node traversed by the translation response floods the 50 27. A method as claimed in claim 26 wherein the called 

called number, PC and ASEA address to every other node in number is truncated to a minimum distinguishing number of 

a same domain. digits before the translation response is returned by the 

17. A method as claimed in claim 16 wherein each node destination IP node. 

traversed by the translation response includes a message 28. A method as claimed in claim 27 wherein each node 

control clock which determines a minimum elapsed time 55 in the PC stack which is traversed by the translation response 

since the node last sent a translation flooding message before message records in its called number translation table the 

a first message can be sent to flood translation response called number, PC and IP address of the IP destination node 

information to other nodes in the same domain. that serves the called number. 

18. A method as claimed in claim 12 wherein the message 29. A method as claimed in claim 32 wherein each node 
type field contains a value that indicates that translation 60 traversed by the translation response includes a message 
query data is not to be provided in response to the query control clock which determines a minimum elapsed time 
message. since the node last sent a flooding message before a first 

19. A method as claimed in claim 1 wherein if a transla- message can be sent to flood translation response informa- 
tion query response message is received at the edge node, tion to other nodes in the same domain. 

the edge node stores the called number, the PC and the 65 30. A method as claimed in claim 28 wherein if a 

ASEA address of the destination ATM node that serves the translation query response message is received at the edge 

called number in its number translation table. node, the edge node stores the called number, the PC and the 
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IF tiuuicss uf the destination IF node ihai serves the called 35. A method as claimed in claim 34 wherein an I AM 

number in its number translation table. message is sent to a destination PSTN network before a 

31. A method as claimed in claim 30 wherein the edge backward setup of a path is begun. 

node floods the called number, the PC and the IP address of 36. A method as claimed in claim 35 wherein connec- 

the destination IP node that serves the called number to all 5 tionless IP voice packets are transferred through the IP 

other nodes in the same domain. network pending the IP path setup. 

32. A method as claimed in claim 27 wherein after 37. A method as claimed in claim 22 wherein the next hop 
recording the called number, PC and IP address of the IP resolution routing table is automatically maintained by the 
destination node that serves the called number, each IP node gateway node which sends address resolution messages to 
traversed by the translation response floods the called 10 neighbouring gateway nodes to request information used to 
number, PC and IP address to every other node in a same maintain data in the next hop resolution routing table, 
domain. 38. A method as claimed in claim 37 wherein the gateway 

33. A method as claimed in claim 25 wherein the message node floods the next hop resolution routing table data to all 
type field contains a value that indicates that translation edge nodes in the same domain. 

query data is not to be provided in response to the query 15 39. A method as claimed in claim 21 wherein a time-out 

message. clock is started when a query message is forwarded and the 

34. A method as claimed in claim 23 wherein the query call is released back to STM facilities if a translation query 
message contains an IP path reservation setup request and on response is not received in response to the query message 
receipt of the query message, the destination IP node begins before the time-out clock has expired. 

a backward setup of a path to the originating IP node, the 20 

path being used for call packet transfer. ***** 
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